Index creation (GSI-327) #13
Conversation
There was a problem hiding this comment.
We delete and recreate databases in test-bed without restarting the services, this can also happen in the production or staging I believe. This approach here solves only a part of issue. It would be better if we have a mechanism that can be triggered anytime @Cito what do you think?
Once we have the production database I am sure it will be steady and untouched so we won't need indexing again but for staging and development it would be useful.
In production or staging databases should only be deleted when first deployed. But in the tests deployments it happens every time. Suggestion: In |
Pull Request Test Coverage Report for Build 5926425191
💛 - Coveralls |
TheByronHimes
dismissed
Cito’s stale review
Changes addressed, Cito out of office, other reviewers
MASS performs text searches in its queries, and an index is needed for that to work.
We need a way to make sure that the indexes exist for each collection corresponding to the configured searchable_classes, ideally at deploy time.
This update adds a way to make sure the collections exist (creating them if needed) and creating the indexes if needed.
I'm not sure about the placement of the function, though, which right now is in both
run_rest()andconsume_events(). I'd appreciate feedback on that in particular.Update: Per feedback, the new function is only called from the load_resources function in QueryHandler. To avoid having the QueryHandler, which is part of the core, interact with the DB directly, I've moved the index creation function to the DaoCollection class. Its job is to provide the DAOs for a given collection, but it's an outbound adapter that deals with the database (indirectly), and seemed suitable for it.